introduction

Bonjour à tous. Dans ce tutoriel nous traiterons d'un programme historique tel que WinZip: arrivés à la dixième incarnation, les programmeurs ont décidé de (enfin) changer la routine

de protection: et c'est là que nous intervenons. Asseyez-vous et profitez de la balade. =)

Pièce jointe

Outils d'occasion

Les outils utilisés:

OllyDbg

Visual Studio 2003 + OpenSSL pour coder le keygen.

RSA Tool v2 facilement trouvé sur goooogle =)

URL ou FTP du programme

Eh bien, il ne faut pas beaucoup d'imagination pour le comprendre.

Rédaction

Très bien, commençons immédiatement à ouvrir le programme avec ollydbg et notons qu'il n'est ni packagé ni rien. Le nag nous accueille d'une manière chaleureuse pour dire le moins, et nous le renvoyons à Enter Registration Code et insérons Graftal comme nom d'utilisateur et 1234567890 comme numéro de série. Bp habituel comme GetWindowText et GetDlgItemText, puis nous faisons OK. Le deuxième de ces points de base nous amène à la zone de code suivante:

Ce qui nous intéresse vraiment ici, ce sont les variables Count qui peuvent aussi nous donner une indication POSSIBLE de la longueur de la série. Nous en avons certainement besoin pour créer le keygen, ne serait-ce qu'en ce qui concerne la longueur maximale du surnom. Il faut maintenant trouver le point de contrôle du feuilleton: faisons attention ici, car le programme est très dispersé et il m'a fallu un moment pour trouver le bon endroit pour aller étudier et inverser. La meilleure chose à faire dans ces cas, c'est de passer par-dessus tout et tout le monde, pour voir s'il y a des variables ou des vérifications qui peuvent attirer notre attention: à ce stade, nous entrerons plus en détail. D'où nous en sommes maintenant dans le code, commençons à passer à un code comme celui-ci:

On peut facilement deviner que l'essentiel du contrôle DEVRAIT avoir lieu dans l'appel que j'ai écrit ci-dessus: en fait, je dans le cas des données que nous avons saisies saute et donc le nom et le numéro de série ne sont pas enregistrés, si ce n'est en tant que périodiques corrects serait sauvé. Faisons F9 et recommençons OK, passons à l'étape et cette fois nous arrivons à l'appel 004133BB (celui ci-dessus en bref), entrons avec F7. À ce stade, nous sommes confrontés à beaucoup de code, pour la plupart absolument inutile. Comment le comprendre? Eh bien, il est important de parcourir tout le code la première fois, puis de trouver l'endroit où "creuser" =). En faisant cela, nous arrivons à ces instructions après un certain temps:

Autre chose à retenir lors du codage du keygen: la longueur du nom d'utilisateur doit être comprise entre 2 et 0x100. Si nous continuons à avancer, nous remarquerons que notre numéro de série apparaîtra aussi, puis c'est tout, l'appel se termine. Nous devons maintenant trouver le bon appel pour faire un pas et analyser. Un premier choix à faire pourrait être d'analyser cet appel:

Puisque nous trouvons notre nom d'utilisateur autour, il est possible que dans l'appel immédiatement en dessous, ou dans ceux qui le suivent, il y ait des instructions intéressantes à analyser. Le premier appel, cependant, même à un coup d'œil très superficiel, nous fait comprendre que rien d'important ne se passe là-dedans. Dans l'appel d'après, on trouve:

Après avoir inversé pendant un certain temps, nous commençons à comprendre que des valeurs telles que 0x7EFEFEFF et autres, en particulier dans ces contextes, sont des appels inutiles pour nos besoins. C'est un excellent critère pour éliminer certains des appels rencontrés en cours de route =). Cela dit (je trouve important d'expliquer certaines manières d '"éliminer" le code indésirable, surtout parce que c'est l'une des raisons qui poussent l'inverseur à abandonner le programme, ou qui en tout cas lui font perdre une myriade de temps ), nous utilisons une garde et très peu de cerveau: si la vérification de la longueur du nom d'utilisateur saisi est postérieure, il est fort probable que tout le code qui le précède ne soit pas nécessaire. En supposant cela, sautons tout jusqu'à ce que nous arrivions au strlen que je vous ai écrit auparavant et en particulier, lorsque nous sommes sur cet appel,

EAX est «bcom», une chaîne que l'on retrouve relativement souvent dans ces instructions: ne soyons pas dupes, c'est inutile est string => même l'appel est inutile. Si vous voulez bien l'analyser, mais sachez que c'est une des façons dont le programme nous fait perdre un temps précieux: il faut être rapide pour trouver l'algo, sinon on s'ennuiera et on le lâchera. Et ce n'est pas bon =). Cependant, le deuxième appel contient déjà quelque chose qui peut attirer l'attention: en prenant un aperçu, on remarque également une constante, 0x1021. Si l'un d'entre vous avait déjà inversé winzip 8 ou 9, vous aurez sûrement remarqué qu'il s'agissait du masque utilisé par le programme pour ensuite générer la série. Une ampoule devrait déjà s’allumer ici. mais si on ne sait rien de la technique de protection des anciennes versions comment comprenez-vous? Pas de problème, passons à l'appel et voyons quel numéro de série est généré:

Et ici dans la pile, immédiatement après l'appel dont (note pour le plus agrammatique: ce n'est pas une erreur, "cui" pas "ici") ci-dessus - qui est en fait un sprintf très simple - on retrouve notre belle série:
" 56AE08A3 "

Ce qui est en fait ma série pour les versions précédentes de winzip .. si vous ne le saviez pas, vous pouvez toujours essayer de la saisir en tant que série pour obtenir un gentil mendiant, ce qui vous dit peut-être même que votre série est ancienne et que vous devriez mettez-le à jour pour la version 10 du programme. Libéré de l'appel, on voit que quelques petites choses sont faites au serial généré il y a peu de temps, et d'autres appels se succèdent, inutiles, les uns après les autres, jusqu'à ce que nous arrivions enfin à notre série:

Maintenant, exactement comme nous l'avons fait auparavant avec notre nom d'utilisateur, maintenant nous commençons à voir si les appels immédiatement en dessous de notre série sont intéressants ou non. Commençons par le premier:

Voici donc un code commenté: je n'y mets que le début de l'appel car il est très long. Si vous avez avancé même un peu superficiellement dans le reste du code, vous remarquerez que d'autres instructions très similaires ou identiques à celles que nous avons analysées auparavant sont répétées, tandis que d'autres totalement nouvelles et que, à première vue, peuvent sembler importantes. Mais comment comprendre que l'appel est presque inutile? Disons que tout d'abord soit on passe un peu le cul, soit on voit que beaucoup, beaucoup de calculs sont effectués, mais au final ni notre série ni notre nom d'utilisateur, ni les longueurs qui peuvent y correspondre ni rien du tout n'apparaissent plus. C'est à ce stade que nous devons analyser un autre appel pour voir si au moins quelque chose s'y passe: sinon, l'appel manqué était probablement important =). Voici le prochain appel:

Entrons à l'intérieur:

Eh bien bien bien .. SU_STD = STANDARD et SU_PRO = PROFESSIONNEL .. au moins théoriquement =). Dans un moment, nous découvrirons si c'est vraiment le cas ou non.
Alors, commençons par entrer dans le premier appel signalé, celui immédiatement en dessous de SU_STD:

Hé hé, qu'est-ce que mes yeux voient! RSA? Si belle! =)
Ce qui est poussé est le contenu d'une clé PEM. Pour certains, une question se posera: qu'est-ce qu'une clé PEM? Disons que c'est un fichier .pem qui est utilisé pour stocker les clés rsa nécessaires pour crypter et décrypter les données. Dans ce cas, nous avons une jolie clé publique (pour des informations détaillées sur le rsa, je vous renvoie au tutoriel evilcry sur le sujet, vraiment sympa). Gardons donc les yeux ouverts pour toutes les fonctions inhérentes à RSA.
Si nous jetons un œil à l'intérieur de l'appel, nous verrons que la bibliothèque winzip appelée wzeay32 contient les fonctions concernant le rsa, et, juste pour donner un exemple, il y a deux appels aux fonctions appelées d2i_RSAPublicKey et PEM_ASN1_read_bio. En effectuant une toute petite recherche sur Internet, puisque j'avais remarqué la nette similitude entre des bibliothèques telles que libeay32 et wzeay32, vous pouvez facilement découvrir que wzeay32 est utilisé pour gérer les fonctions OpenSSL dans winzip =). Gardons à l'esprit que nous en aurons besoin plus tard pour créer le keygen (bien que ce ne soit pas essentiel).

Maintenant, commençons à avancer, en gardant à l'esprit que lorsque nous rencontrons du code dans lequel une chaîne est poussée qui a comme contenu ".. \ .. \ common \ WzReg.c" ou quelque chose de similaire, l'appel immédiatement précédent est inutile et donc ne le faisons pas perdre du temps à l'analyser. Cela dit, continuons à avancer, jetons un coup d'œil en appuyant sur Entrée lorsque nous sommes en ligne pour voir si cela fait du bien, et sinon, continuez jusqu'à ce que nous arrivions ici:

Voyons ce qui nous attend:

Voici une chose fondamentale: notre série a une longueur de 0x0B (car le zéro final est également compté) alors qu'elle devrait contenir des caractères 0x1E. Faisons F9 et insérons cette série: 12345678901234567890123456789. Ok, revenons à l'endroit où nous étions auparavant, prenons quelques autres vérifications qui ont réussi, jusqu'à ce que nous atteignions cette boucle:

Je ne l'ai pas commenté car il y a peu à comprendre: il supprime simplement de la série tous les tirets qui devraient être là, mais que nous n'avons pas encore mis, et repositionne les caractères dans la chaîne pour qu'il n'y ait pas de "trous" (nous venons de supprimer les tirets, alors ..). Gardez toujours à l'esprit que 0x2D = '-'. Immédiatement après cette boucle, il y a un bel appel que nous allons analyser en profondeur car il est fondamental. Voyons comment ça commence:

Eh bien, nous devons donc mettre beaucoup de tirets jusqu'à ce que notre 29 devienne un multiple de 5. Alors mettons 4 jolis tirets et faisons notre série comme ceci: 12345-78901-34567-90123-56789
Attention à REMPLACER les caractères qui étaient là avant avec les tirets, et de ne pas les ajouter, sinon le chèque que nous avons analysé avant donne mendiant off =). Le code que je vous montre maintenant est très long, mais n'ayez pas peur, j'explique les choses vraiment importantes là-dedans et immédiatement après je vais tout clarifier en vous l'expliquant sans les commentaires, car ce serait un gâchis monstrueux à faire les deux choses ensemble:

Ok, essayons d'expliquer organiquement: que se passe-t-il au début de la boucle? En pratique, il prend les caractères du nom d'utilisateur et soustrait une valeur par défaut du code ascii en fonction de la valeur de caractère extraite de la série. Par exemple, si le caractère est un nombre (et est donc compris entre 0x30 et 0x39), il soustrait 0x1A et ainsi de suite. Cela sert à avoir une valeur où les bits significatifs sont au maximum 5. Après cela, dans la deuxième partie de la boucle si vous remarquez qu'il y a un commutateur avec 8 maisons .. 8 comme les bits qui composent un octet non? =) Bref, voici pratiquement ce que ça fait: imaginez courirla PREMIÈRE partie de la boucle pour tous les caractères de la série (celle qui fait SEULEMENT les soustractions), afin d'obtenir une série de valeurs. Imaginez maintenant de mettre dans un seul conteneur, disons une chaîne par exemple, tous les 0 et 1 qui composent les octets. Que verriez-vous? Eh bien, que les 3 premiers bits de chaque octet sont valides0. A ce stade alors, le programme supprime simplement ces 3 bits et déplace tout pour avoir une variable qui ne contient plus ces 3 bits. Mais donc ce que nous avions avant est "détruit" puisque maintenant les groupes de 8 bits qui composent 1 octet sont un ensemble de bits pris maintenant d'un caractère, maintenant d'un autre. Pour être clair, voici un exemple très simple:

Nous avons ces 3 octets

10011011 11110101 10111100

À travers la première partie de la boucle, nous les transformons en:

00011011 00010101 00011100

À travers la deuxième partie de la boucle, nous supprimons les 3 bits initiaux et transformons tout en ceci:

11011 10101 11100

Alors maintenant, le premier octet, juste pour donner un exemple, sera:

11011101

Et ainsi de suite pour tous les autres octets. Comme vous pouvez le voir, c'est très différent de ce que nous avions auparavant (100011011). Mais les caractères sont des multiples de 5 (contrairement à mon exemple) et donc au final en supprimant 3 bits de chaque octet, il est possible de former un nombre "droit" d'octets (il ne reste plus de bits qui n'atteignent pas l'octave., comme dans mon exemple). D'accord, j'espère que c'est clair, car c'était une partie importante =) (sinon, relisez le tout ou envoyez-moi un e-mail).

Nous arrivons ici à une autre partie importante: la génération d'un octet particulier. Jusqu'à présent, nous avons vu que le programme prend notre série, le modifie de manière appropriée pour obtenir une chaîne de 120 bits (15 caractères ASCII). Cette chaîne, notre "série numérique", a un octet final qui doit être très particulier. Le programme, dans le morceau de code ci-dessous, se donne pour tâche de vérifier sa validité effective; voyons selon quels paramètres:

Donc, comme vous pouvez le voir, il s'agit d'une double boucle. Je vais vous expliquer maintenant comment cela fonctionne. Fondamentalement, il prend le nombre 0x80 (qui est un nombre qui est transformé en binaire vaut 1000000) et fait un et ('test') vérifie si le premier bit du premier octet de notre "série numérique" est égal à 1. Si c'est, je ne saute pas et bl, qui prend en compte tous les bits qui sont 1 dans les 25 premiers bits de la série numérique, est incrémenté. Pourquoi ai-je mentionné les 25 premiers bits? Voyons ce que contient edi: les 4 premiers dwords sont égaux à 0x19 et le dernier à 0x14. Si vous ajoutez tout cela, vous voyez que c'est 0x78, qui est 120. Comme nos bits =). De cela, nous comprenons que winzip compte combien de bits = 1 il y a dans les 25 premiers bits de la série numérique, puis dans les 25 suivants et ainsi de suite jusqu'à ce qu'il n'en reste plus que 20.0100000 en binaire, 0x20 est 0010000 et ainsi de suite jusqu'à 1. Cela vous permet de vérifier les 8 bits. À la fin de tout cela, nous avons 5 valeurs (comme les 5 dwords contenus dans edi). La deuxième partie de la boucle explique ce que fait le programme avec ces 5 valeurs: tout d'abord il définit une variable = 7, puis prend la première valeur, la divise par deux, fait un shl entre le reste de la division et cette valeur initialement égale à 7. Le résultat est xé avec le dernier octet de la série numérique et un et est fait entre les deux valeurs: si le résultat est 0, alors tout va bien, si c'est 1, il saute au mendiant. A chaque boucle, le premier 7 est décrémenté.

Ok, nous avons presque terminé, attendez =). Si nous regardons le reste de l'appel dans lequel nous sommes, nous voyons deux appels intéressants: RSA_public_decrypt et SHA1.

NOM 

RSA_private_encrypt, RSA_public_decrypt - opérations de signature de bas niveau

SYNOPSIS 

 #include < openssl / rsa.h >

 int RSA_private_encrypt (int flen, unsigned char * from,

    unsigned char * to, RSA * rsa, int padding);

 int RSA_public_decrypt (int flen, unsigned char * from,

    unsigned char * to, RSA * rsa, int padding);

LA DESCRIPTION 

Ces fonctions gèrent les signatures RSA à un niveau bas.

RSA_private_encrypt () signe les Flen octets à partir (généralement un condensé de message avec un algorithme d' identification) à l' aide de la clé privée rsa et stocke la signature à . to doit pointer vers RSA_size (rsa) octets de mémoire.

padding désigne l'un des modes suivants:

RSA_PKCS1_PADDING

Rembourrage PKCS # 1 v1.5. Cette fonction ne gère pas l' algorithmeIdentifier spécifié dans PKCS # 1. Lors de la génération ou de la vérification des signatures PKCS # 1, rsa_sign (3) et rsa_verify (3) doivent être utilisés.

RSA_NO_PADDING

Signature RSA brute. Ce mode doit uniquement être utilisé pour mettre en œuvre des modes de remplissage du son cryptographiquement code d'application. La signature directe des données utilisateur avec RSA n'est pas sécurisée.

RSA_public_decrypt () récupère le condensé de la Flen octets de long signature à partir en utilisant la clé publique du signataire rsa . to doit pointer vers une section mémoire suffisamment grande pour contenir le résumé du message (qui est plus petit que RSA_size (rsa) - 11 ). padding est le mode de remplissage utilisé pour signer les données.

VALEURS DE RETOUR 

RSA_private_encrypt () renvoie la taille de la signature (c'est-à-dire RSA_size (rsa)). RSA_public_decrypt () renvoie la taille du résumé de message récupéré.

En cas d'erreur, -1 est renvoyé; les codes d'erreur peuvent être obtenus par err_get_error (3).

C'est la description des fonctions RSA_public_decrypt et des RSA_private_encrypt complémentaires (ce dernier que nous utiliserons dans le keygen). Donc notre fameux "série numérique" doit être une valeur retournée par RSA_private_encrypt, après quoi le programme va le déchiffrer et obtenir un nombre. Voyons tout cela, et voyons aussi bientôt ce qui est fait avec ce numéro:

Si vous avez fait le suivi d'un vidage, gardez à l'esprit la valeur du premier dword, car nous le retrouverons bientôt.

En allant un peu plus loin dans la liste, il y a la fonction de hachage SHA1. Si j'étais vous, j'aurais déjà deviné ce qui va se passer, mais je ne gâcherai pas encore la surprise: P.

SYNOPSIS 

#include <openssl / sha.h>

 unsigned char * SHA1 (const unsigned char * d, unsigned long n,

                  unsigned char * md);

LA DESCRIPTION

SHA1()calcule le résumé de message SHA-1 des n octets en d et le place dans md (qui doit avoir de l'espace pour SHA_DIGEST_LENGTH == 20 octets de sortie). Si md est NULL, le condensé est placé dans un tableau statique.

Maintenant que nous savons quels paramètres prend la fonction de hachage, voyons le désasme:

Tout cela n'était pas vraiment fondamental, nous trouvons la partie importante dans l'appel que j'ai marqué pour vous et que nous allons maintenant analyser, même si ce n'est pas très minutieusement, car cela ne sert à rien:

Hé hé hé! Qu'est ce que je vois! =)

Dans edi se trouve la valeur trouvée par la fonction RSA_public_decrypt! Mais c'est gentil hein? Voici le "secret": si la fonction RSA renvoie le hash de notre nom d'utilisateur, nous sommes enregistrés =).

Ok, on a beaucoup parlé du RSA mais .. tu ne penses pas qu'il manque encore quelque chose pour compléter le tableau? Ouais, qu'en est-il des clés? Où les mettons-nous? Lesquels sont-ils? =). Toutes les questions auxquelles je vais répondre sous peu. Tout d'abord, rappelez-vous que le programme avait deux modes d'enregistrement,le SU_STD e le SU_PRO? Voyons ici quelle clé SU_STD et SU_PRO utilise dans la fonction RSA_public_decrypt:

Comme il s'agit d'une structure bignum, cela peut être un peu déroutant au début, mais en regardant un peu plus bas notre joli Follow in dump, nous pouvons voir une belle rangée de nombres longs 0x0F qui sont également pointés un peu plus haut dans la structure. En l'occurrence, la fonction prend 0x0F octets. Sera-ce une coïncidence? Naa: P. Evidemment, marquez ces octets au contraire et voici la première clé, notre N pour le SU_STD: E31557F66498F138597E6EA3ABDCEF.

Répétant la même chose pour le SU_PRO: 9D845872E117501775DD51D9044945.

Maintenant, utilisez RSA Tool v2 (si vous ne l'avez pas, recherchez-le sur Google et trouvez-le, il est relativement bien connu) et dites-lui de trouver p et q, sans vous soucier de l'exposant qui est l'habituel 0x10001. J'écris toutes les données ici:

SU_STD:

n = E31557F66498F138597E6EA3ABDCEF

p = EC5A57BA9E77CFB

q = F5F5BE226C8F59D

e = 0x10001

d = 16B67CCCD53502F0870D775052FB49

SU_PRO:

n = 9D845872E117501775DD51D9044945

p = C2C17D26DBC6E83

q = CF0D008F6995E97

e = 0x10001

d = 1E84F8063A2AA42B29DD5578421E79

Ils sont tous dérivés de l'outil RSA. Avec ces données, nous pouvons enfin coder le keygen =).

~ KeyGen ~

Concernant le keygen, il n'y a pas grand chose à dire: je résume ici les étapes du keygen et j'attache le src au keygen que j'ai créé. Je ne veux pas, j'avais commencé à écrire le keygen en asm, mais quand j'ai décidé d'implémenter OpenSSL j'ai préféré l'écrire en C: par conséquent, certaines pièces sont faites en asm dans le source, mais elles se comprennent assez bien; disons simplement que c'est anti-esthétique. Et puis si vous ne les comprenez pas, qu'allez-vous inverser? : P

Ok alors, notre keygen doit faire exactement ceci:

1)      Prenez le nom d'utilisateur et mettez-le en minuscules.

2)      Hash la chaîne obtenue.

3)      Initialisez les clés RSA.

4)      Faites un RSA_private_encrypt sur notre hachage.

5)      Créez le dernier octet en comptant les bits = 1 présents dans les autres.

6)      Créez la série en caractères en effectuant le processus inverse effectué par le programme et en mettant les tirets.

7)      Tout cela pour les deux types de séries bien sûr, standard et professionnel.

Ici, comme devoirs, codez un joli keygen propre et envoyez-moi le src comme d'habitude au mail latfarg (at) gmail (dot) com =).

Greffe

Notes finales

C'était le tutoriel, j'espère que vous l'avez apprécié : P. Il m'a fallu beaucoup de temps pour l'écrire en raison du manque de temps ( : P), mais à la fin je l'ai fait. Je voudrais remercier tous ceux que je connais, en particulier Eimiar, le mythique cri diabolique ; ), le clan UT2004 auquel j'appartiens et comme toujours le Que qui publie très gentiment mon matériel: P.

Si vous avez des commentaires, des conseils, des doutes, envoyez tout à latfarg (at) gmail (dot) com = )

À la prochaine.

Avertissement

Je vous rappelle que le logiciel doit être acheté et non volé, vous devez enregistrer votre produit après la période d'évaluation. Je ne suis pas responsable des dommages causés à votre ordinateur par une mauvaise utilisation de ce didacticiel. Ce document a été écrit pour inciter le consommateur à enregistrer légalement ses programmes, et non pour lui faire utiliser les nombreux fichiers de crack sur le net, en fait ce document aide à comprendre l'effort que chaque développeur a dû faire pour fournir son consommateurs respectifs, les meilleurs produits possibles.

Nous l'inversons à titre informatif uniquement et pour améliorer nos connaissances du langage d'assemblage.